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Abstract 

This  report  provides  a  basic  overview  of  design  philosophies 
and  implementations  of  the  DTNSRDC  Computer  Center's 
Accounting  Scheme  (CAS)  for  the  Scientific  and  Engineering 
(S&E)  VAX  Systems.  These  systems  are  running  the  VAX/VMS 
Operating  System  -  Version  4.2  (VMS),  and  are  maintained  by 
Code  189. 

Administrative  Information 

The  work  described  in  this  report  was  performed  in  the  Systems 
Software  Group  (1892.3)  of  the  Computation,  Mathematics  and 
Logistics  Department,  David  W.  Taylor  Naval  Ship  Research  and 
Development  Center  under  sponsorship  of  the  DTNSRDC  Computer 
Center  (189). 


Introduction 

VMS,  the  supported  operating  system  for  Digital's  VAX  series 
of  super  mini-computers,  provides  resource  accounting 
information  to  the  system  management  personnel  which  can  be 
used  to  generate  reports  summarizing  the  resource  utilization 
of  the  VAX  Systems.  These  reports  include  summaries  of  CPU 
time.  Connect  time,  I/O  time,  tape  mounts,  pages  printed  and 
disk  space  utilization.  VMS  assumes  that  each  user  will  be 
authorized  for  only  one,  eight-character  account  number.  189 
has  specific  needs  in  an  accounting  package  which  are  not 
standard  features  under  VMS.  Among  these  needs  are  the 
ability  to  allow  users  to  charge  to  specific  job  order  numbers 
for  specific  projects,  provide  accounting  analysis  across  the 
VAXcluster,  and  to  provide  a  method  of  interfacing  VMS'  eight 
character  ACCOUNT  field  with  a  ten  character  job  order  number. 

This  paper  details  the  required  accounting  enhancements  for 
the  Center,  broken  down  into  five  sections:  UPDATE,  LOGIN, 
Advantages  and  Disadvantages  of  CAS  vs.  VMS,  ANALYZE  and 
Future  Enhancements.  -The  UPDATE  section  will  include  a  USER'S 
GUIDE  to  the  UPDATE  procedure  for  authorizing  users  to  CAS  and 
VMS.  The  LOGIN  section  deals  with  the  inner  workings  of  CAS, 
and  how  it  taylors  the  user  environment  for  multiple  job 
order-  numbered  users.  The  ANALYZE  section  describes  the 
group  of  routines  which  use  the  VMS  Accounting  Utility  to 
extract  resource  accounting  information  that  can  be  processed 
by  local  routines  to  provide  Code  189.3  a  resource  summary 
with  appropriate  charges.  In  addition,  the  other  two  sections 
deal  with  the  advantages  and  disadvantages  of  CAS  vs.  VMS, 
and  some  future  enhancements  to  CAS.  Please  note  that  any 
routines  discussed  in  this  paper  are  under  the  cognizance  of 
the  VAXcluster  System  Manager  and  are  not  available  for 
general  use. 
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1  UPDATE 

Frequently  Used  Terms/  Abbreviations 
Abbreviations: 


1. 

2. 

3. 

4. 

5. 

6. 
7. 


CAS  -  Computer  Center  Accounting  Scheme 

UAF  -  User  Authorization  File 

UIC  -  User  Identification  Code 

ATF  -  Accounting  Transfer  File 

CAF  -  Computer  Center  Authorization  File 

PAF  -  Project  Accounting  File 

UDF  -  User/  Device  File 


Definitions: 


1.  UAF  -  file  which  VMS  uses  to  make  the  system 

resources  available  to  users.  Holds  UIC,  ACCOUNT, 
Default  Directory,  etc. 

2.  UIC  -  a  code  which  is  written  to  data  structures 
indicating  ownership  and  is  used  to  determine 
access  to  files  and  devices. 

3.  CAF  -  file  which  CAS  uses  to  make  the  system 

resources  accountable  to  users.  Holds  UICs, 
ACCOUNTS,  Default  Directories,  Account  Numbers, 
User  Initials,  etc. 

4.  PAF  -  file  which  CAS  uses  to  make  the  system 

resources  accountable  at  the  project/ (account) 
level.  Holds  job  order  numbers,  and  the  number  of 
users  allowed  to  charge  to  each  job  order  number. 

5.  UDF  -  file  which  CAS  uses  to  determine  which  device 
to  add  a  new  user  to.  Holds  device  names,  number 
of  accounts  currently  residing  on  each  device,  as 
well  as  which  device  has  the  most  users. 
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6.  Account  Number  -  a  field  in  the  VMS  process  data 
structures 

7.  Job  Order  Number  -  Defined  by  DTNSRDC  Financial 
Management  Department 

8.  ACCOUNT  -  general  term  for  access  to  a  computer 
system.  (ie.  USERNAME,  PASSWORD,  Job  Order 
Number) 

9.  AUTHORIZE  -  the  addition  of  a  user  to  the  CAF,  PAF, 
UDF  and  UAF 

10.  UPDATE  -  local  routine  to  authorize  users  and 
guarantee  that  the  data  in  the  VMS  and  CAS 
accounting  files  is  consistent 


FUNDAMENTALS: 


1.  UICs  -  [Group,  Member] 

Group  -  each  user  forms  a  unique  group 
(default) 

Member  -  each  user  is  a  unique  member  within 
the  group 

2.  USER  -  forms  a  unique  group  regardless  of  how  many 
job  order  numbers.  (default) 

3.  USER  INITIALS  -  4  characters  which  uniquely 

identify  a  user  from  all  other  users.  These 

initials  are  the  same  for  each  user  on  all  of  the 
computers  managed  by  the  Computer  Center. 

A.  USERNAME  -  same  as  the  User  Initials.  (default) 
However,  USER  INITIALS  appended  with  1-8  characters 
are  allowed  as  special  cases  for  system  maintenance 
only. 

5.  FULLNAME  -  a  1-31  character  identifier  which 

uniquely  identifies  each  USER.  Typically  the 
USER'S  surname. 
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6 .  ACCOUNT  NUMBER 

each  user  may  charge  to  one  or  more  job  order 
numbers 

this  associates  charges  to  job  order  number 

this  field  is  8  characters  in  length  and 
appears  in  the  ACCOUNT  field  in  the  USER'S 
process  data  structures.  (The  10  character  job 
order  number  is  packed  into  this  field) 


7.  ACTIVE/  INACTIVE 

either  a  user,  or  one  of  a  user's  job  order 
numbers  may  be  made  inactive  due  to  depleted 
funds,  or  a  number  of  other  reasons. 

-  when  made  inactive,  users  are  not  allowed  to 
charge  any  more  resources  against  the  account 
or  job  order  numbers  which  have  been  disabled. 

~  a  user  may  request  that  an  account  be  made 
inactive  while  the  user  is  on  travel,  etc.,  as 
an  added  security  feature. 
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UPDATE  STARTUP  AND  MAIN  MENU  DESCRIPTION 

1.  To  execute  UPDATE,  enter  @UPDATE 

2.  Once  this  is  entered,  UPDATE  produces  the  Main  Menu 
and  prompts  for  an  option: 


1. 

ADD 

-  add  a  new  user  to  the  system 

2. 

LIST 

-  produce  a  listing  of  system  users 

3. 

DISABLE 

-  disable  a  user 

A. 

ENABLE 

-  enable  a  user 

5. 

REMOVE 

-  remove  a  user  from  the  system 

6. 

MODIFY 

-  modify  charge  codes 

7. 

HELP 

-  produce  details  about  the  commands 

8. 

STOP 

-  terminate  this  program 

Multiple  ACCOUNT  Implementation  For  VAX/VMS 
UPDATE 

FULL  EXPLANATION  OF  OPTIONS: 

A.  ADD: 

1.  This  option  adds  elements  to  the  CAS  files: 
CAF,  PAF,  UDF,  and  the  VMS  System  User 
Authorization  File. 

2.  All  elements  added  (USERNAME,  FULLNAME, 

ACCOUNT,  etc.)  are  added  with  a  default  of 

ACTIVE. 

3.  The  ADD  module  only  prompts  for  the  following 
information: 

a.  User  Initials 

b.  FULLNAME  (if  new  user) 

c.  ACCOUNT  Number 

d.  USERNAME 

A.  The  ADD  module  automatically  assigns  the 

following: 

a.  UIC  [Group,  Member] 

b.  Initial  password 

c.  Default  Directory 

d.  Default  Device 

e.  Default  Protections 

f.  Privileges 

g.  ACTIVE  flag 

5.  If  ADD  detects  an  error  it  outputs  an 

informative  message,  and  saves  temporary  files 
created  for  this  operation  for  checking 

6.  A  success  message  is  displayed  that  indicates 
the  addition  of  the  user  to  the  following: 
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a.  CAF 

b.  PAF 

c.  UAF 

d.  UDF 


B.  LIST: 

1.  This  option  generates  a  listing  of  both  the  CAF 
and  PAF  which  can  also  be  displayed  at  the 
terminal 


C.  DISABLE: 

1.  This  option  disallows  a  user  to  login.  This 
feature  is  handy  when  a  user  goes  on  extended 
leave. 


D.  ENABLE: 

1.  This  option  allows  a  user  who  has  been  DISABLED 
to  login. 


E.  REMOVE: 

1.  This  option  removes  a  user  from  the  system. 
The  user  no  longer  has  access  to  the  system, 
and  all  files  will  be  deleted  once  they  have 
been  backed  up  to  tape. 

2.  The  actual  deletion  of  the  user  is  completed 
manually. 


F.  MODIFY: 

1.  This  option  allows  the  modification  of  one  or 
more  of  the  job  order  numbers  the  user  has  been 
authorized  for.  There  are  four  modification 
operations : 

a.  CHANGE:  CHANGE  replaces  all  occurrences  of 
the  old  account  number  with  the  new  account 
number.  This  option  is  especially  useful 
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at  the  end  of  a  fiscal  year  when  all  of  the 
account  numbers  are  changed. 

b.  DELETE:  This  option  deletes  a  job  order 
number  from  a  user.  Files  will  be  backed 
up  to  tape  at  the  next  opportunity. 
Deletion  can  occur  by  specifying  an 
individual  user  or  all  users  authorized  for 
that  job  order  number. 

c.  ACTIVATE:  This  re-enables  a  job  order 

number  by  specifying  a  single  user,  or  all 
users  authorized  for  that  job  order  number. 
Users  are  then  allowed  to  charge  system 
resources  to  the  job  order  number  which  has 
been  reactivated. 

d.  INACTIVATE:  This  works  just  the  opposite 
of  the  way  ACTIVATE  works.  Users  are 
disallowed  to  charge  system  resources  to 
the  INACTIVATED  job  order  number  until  it 
has  been  re-activated. 


G.  HELP:  This  option  produces  a  full  description  of 
the  commands  in  the  main  menu.  After  this 
information  has  been  output,  the  program  returns  to 
the  main  menu  and  prompts  for  the  desired  option. 

H.  STOP:  This  option  allows  the  user  to  terminate  the 
UPDATE  procedure. 
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1.5  UPDATE  USER'S  GUIDE 

(The  following  are  examples  of  the  interfaces  between 
UPDATE  and  the  individual  executing.  For  purposes  of 
clarity  in  this  example,  when  UPDATE  expects  a  response, 
a  colon  will  appear  at  the  end  of  the  last  line  output  by 
UPDATE,  and  sample  responses  will  be  represented  by  <Z>, 
where  Z  is  the  input  entered;  <CR>  indicates  striking  the 
return  key  without  entering  anything  beforehand.  In 
addition,  x  indicates  a  variable  numeric.) 

A.  ADD 

The  four  most  popular  occurrences  of  ADDing  a  user 
follow  - 


1.  ADDing  a  new  user,  ABCD,  to  an  existing  account, 
taking  the  default  device,  UIC  Group,  and  UIC 
Member  chosen  by  ADD. 

ACCOUNT  NUMBER:  <0123456789> 

USER  INITIALS  :  <ABCD> 

*  new  user  * 

ENTER  FULLNAME:  <John  Doe> 

ENTER  USERNAME:  <ABCD> 

Enter  1,2,3<CR>  :  <CR> 

..  next  device  is  ...  USERDISKx 

Next  GROUP  is  [000400] .  Hit  (N)  to  enter  another:  <CR> 
Default  MEMBER  is  [000400].  Hit  (N)  to  change:  <CR> 
(success  or  failure  message) 

WOULD  YOU  LIKE  TO  ADD  ANOTHER?  : 

2.  ADDing  another  account  to  an  existing  user  and  an 
existing  account  - 

ACCOUNT  NUMBER:  <0123456789> 

USER  INITIALS  :  <John  Doe> 

WOULD  YOU  LIKE  TO  ADD  ANOTHER?  : 

3.  ADDing  an  account  to  an  existing  user  where  the 
account  is  new  - 

ACCOUNT  NUMBER:  <01234567890> 

USER  INITIALS:  <ABCD> 

*  new  account  -  confirm  (Y)  *  :  <CR> 

WOULD  YOU  LIKE  TO  ADD  ANOTHER?  : 
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A.  ADDing  a  new  user,  ABCD,  to  an  account  which  does 
not  exist  and  taking  the  default  Device,  UIC 
Group  and  UIC  Member  chosen  by  ADD. 

ACCOUNT  NUMBER:  <0123456789> 

*  new  account  -  confirm  (Y)  *  :  <CR> 

USER  INITIALS:  <ABCD> 

*  new  user  * 

ENTER  FULLNAME:  <John  Doe> 

ENTER  USERNAME:  <ABCD> 

Enter  1,2,3<CR>  :  2 

..  next  device  is  ...  USERDISK2 

Next  GROUP  is  [000500] .  Hit  (N)  to  enter  another: 

<CR> 

Default  MEMBER  is  [000500] .  Hit  (N)  to  change: 
<CR> 

(success  or  failure  message) 

WOULD  YOU  LIKE  TO  ADD  ANOTHER?  : 


B.  LIST: 

Hit  Y  to  display  CAF  at  the  terminal  :  <Y> 
Hit  Y  to  display  PAF  at  the  terminal  :  <CR> 

C.  DISABLE: 


Enter  INITIALS:  <ABCD> 

ABCD  has  been  DISABLED  in  the  UAF 
Would  you  like  to  DISABLE  another?  : 

D.  ENABLE: 

Enter  INITIALS:  <ABCD> 

ABCD  has  been  ENABLED  in  the  UAF 
Would  you  like  to  ENABLE  another?  : 

E.  REMOVE: 


Enter  INITIALS:  <ABCD> 

ABCD  has  been  DISABLED  in  the  UAF  pending  deletion 
Would  you  like  to  REMOVE  another?  : 

F.  MODIFY: 

Enter  which  modification  option  you  want  ~ 

Change,  Delete,  Activate,  Inactivate 

1 .  Change 


Enter  Old  Account:  <0123456789> 
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Enter  New  Account:  <9876543210> 

-  Enter  <CR>  to  terminate  loop!  - 
Enter  Initials:  <ABCD> 

User  ABCD's  account  0123456789  has  been  changed 
to  9876543210 

-  Enter  <CR>  to  terminate  loop!  - 
Enter  Initials:  <CR> 

Would  you  like  to  change  another  Account  ?  : 

2 .  DELETE 

Enter  ACCOUNT:  <0123456789> 

•  -  Enter  <CR>  to  terminate  loop!  - 
Enter  INITIALS:  <ABCD> 

Account  0123456789  has  been  successfully  modified 
for  ABCD 

Enter  INITIALS:  <CR> 

..  PAF  entry  0123456789  successfully  modified  ... 
Would  you  like  to  delete  another  Account  ?  : 

3.  ACTIVATE 
Enter  ACCOUNT: 

-  Enter  <CR>  to  terminate  loop!  - 
Enter  INITIALS:  <ABCD> 

Account  0123456789  has  been  successfully  modified 
for  ABCD 

Enter  INITIALS:  <CR> 

Would  you  like  to  CHANGE  another  ACCOUNT?  : 

4.  INACTIVATE 
Enter  ACCOUNT: 

-  Enter  <CR>  to  terminate  loop!  - 
Enter  INITIALS:  <ABCD> 

Account  0123456789  has  been  successfully  modified 
for  ABCD 

Enter  INITIALS:  <CR> 

Would  you  like  to  CHANGE  another  ACCOUNT?  : 


G.  HELP: 

H.  STOP: 
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2  LOGIN 

A  method  needed  to  be  developed  to  give  users  an 
opportunity  to  charge  to  different  job  order  numbers  when 
working  on  various  projects  simultaneously.  189  considered 
assigning  different  accounts  for  each  job  order  number  that 
the  user  wished  to  charge  to,  but  decided  to  allow  each 
user  to  have  only  one  VMS  account,  and  to  allow  them  to 
charge  to  as  many  job  order  numbers  as  they  required.  The 
scheme  works  as  follows: 

1.  When  a  user  is  first  authorized  to  the  VMS  system,  (see 
UPDATE,  section  1,1. A  A;  the  ADD  module),  the  Computer 
Center  assigns  the  user  a  username.  In  addition,  the 
CAS  files,  CAF,  PAF,  and  UDF  are  updated  to  reflect  the 
job  order  number(s),  and  default  device  to  be 
associated  with  this  account.  When  a  user  logs  on  to 
VMS,  a  local  routine,  CAS_SYLOGIN,  intercepts  after  VMS 
has  successfully  'logged  in'  the  user,  and  determines 
if  the  user  has  been  authorized  for  only  one,  or  more 
than  one  job  order  number. 

2.  If  the  user  is  authorized  for  only  one  job  order 
number,  then  a  privileged  routine,  GETACCT,  extracts 
the  user's  ten  character  job  order  number  from  the 
appropriate  record  in  the  CAF. 

a.  GETACCT  then  packs  the  job  order  number  into  eight 
bytes  and  stores  it  in  the  VMS  ACCOUNT  field  in  the 
user's  process  data  structures  before  returning 
control  to  CAS_SYLOGIN.COM. 

b.  The  Computer  Center's  INIT.COM  procedure  is 
executed  to  define  symbols  and  logicals  as  an  aid 
to  the  user. 

c.  User's  default  directory  is  set 

d.  LOGIN.COM  residing  in  the  user's  default  directory 
is  executed. 


3.  If  an  interactive  user  has  been  authorized  for  more 
than  one  job  order  number,  then  CAS_SYLOGIN  behaves 
differently.  After  detecting  the  multiple  job  order 
numbered  user: 

a.  INTERACTV,  a  privileged  routine,  prompts  the  user 
via  the  SYSSQIO  VMS  System  Service,  for  the  desired 
job  order  number. 
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b.  The  user  is  given  three  attempts  to  enter  a  ten 
character  code  which  matches  one  of  those  which  are 
under  that  user  in  the  CAF. 

c.  Prompts  are  timed  so  that  the  connection  will  be 
dropped  if  nothing  is  entered.  The  number  entered 
by  the  user  not  only  must  be  in  the  CAF,  but  also 
must  be  ACTIVE. 

d.  INTERACTV  then  packs  the  job  order  number  into  the 
VMS  ACCOUNT  field  the  same  way  GETACCT  does. 

e.  Control  then  returned  to  CAS_SYLOGIN.COM  for 
executing  INIT.COM,  setting  the  default  directory, 
and  executing  the  user's  LOGIN.COM. 


4.  Batch  jobs  from  users  with  more  than  one  job  order 
number  are  required  to  contain  a  job  order  number  in 
columns  1-10  of  the  first  record  of  the  job. 

a.  A  privileged  routine  BATCH,  compares  this  job  order 
number  with  the  active  job  order  numbers  in  the 
user's  CAF  record(s). 

b.  If  the  job  order  number  is  invalid,  an  informative 
message  is  written  to  the  logfile,  and  the  job  is 
terminated. 

c.  If  the  job  order  number  is  valid,  BATCH  packs  the 
job  order  number  into  the  VMS  ACCOUNT  field  like 
GETACCT  and  INTERACTV  do  it. 

d.  BATCH  then  returns  control  to  CAS_SYLOGIN.COM  for 
executing  INIT.COM,  setting  the  default  directory, 
and  executing  the  user's  LOGIN.COM. 


Thus  far  we  have  seen  only  one  difference  between  CAS  and 
standard  VMS  -  a  multiple  job  order  number  user  is  prompted 
for  the  job  order  number  interactively,  and  must  supply  a 
job  order  number  as  the  first  record  of  a  batch  job.  With 
these  enhancements  we  have  effectively  solved  the  problem 
of  the  conversion  between  ten  character  job  order  numbers 
and  the  eight  character  VMS  ACCOUNT  field,  and  have  also 
successfully  accounted  for  users  who  need  to  work  for 
multiple  projects.  However,  we  have  left  out  one  very 
important  aspect  -  how  does  one  charge  for  the  filespaee 
for  a  user  with  multiple  job  order  numbers? 
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A  number  of  alternatives  were  considered.  Even  modifying 
the  VMS  file  header  was  considered,  but  rejected  due  to  the 
obvious  vulnerablilties  to  VMS  which  would  be  made  by  such 
a  decision.  The  solution,  though  strange  in  appearance  to 
the  users,  is  both  functional  and  protective  to  the  VMS 
file  system.  189  chose  to  treat  the  user's  root  directory 
as  VMS  treates  the  Master  File  Directory  (MFD).  That  is, 
it  is  owned  and  controlled  by  the  System;  a  user  cannot 
alter  files  directly  below  it.  In  addition,  subdirectories 
of  the  root  directory  are  created  which  are  treated  like 
VMS'  root  directories  of  the  form,  JONx.DlR;l  -  where  x  is 
the  job  order  number  to  be  charged  for  these  files.  One 
JON  directory  is  created  for  each  JON  the  user  is 
authorized  for.  (see  Fig.  2.1,  2.2)  During  the  login 
process  the  user  automatically  defaults  to  the  JONx 
subdirectory  which  corresponds  to  the  job  order  number 
being  charged  for  that  session. 
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Standard  VMS 


DEVICE:  [000000]  <— 

/  1  \ 

/  !  \ 

[USERl]  [USER2]  [USERx] 


FIG.  2.1 


CAS  Implementation 


DEVICE: [000000]  < -  MFD  (Master  File 

/  ...  !  ...  \  Directory) 

/  !  \ 

[USERl]  [USER2]  [USERz]  Root  Directory 
/  /  ...  \  |  (Treated  like  VMS  MFD) 

/  /  \  - 

/  /  \  : 

[USERl. JONx]  [USER2. JONx]  [USER2.JONy]  j 

1 

•  •  •  I 

[USERz. JONw] 

.  .  .  (User  'owns'  files  under  here) 

.  .  .  (Treated  like  VMS  Root 

.  .  .  Directory) 


FIG  2.2 


—  MFD  (Master  File 
Directory) 

Root  Directory 
(User  'owns'  files 
under  here) 
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3  ADVANTAGES/DISADVANTAGES  OF  CAS  VS.  STANDARD  VMS 


1 .  ADVANTAGES 

1.  A  user  with  one  job  order  number  sees  no 
difference  from  standard  VMS  except  for  the 
longer  path  name  to  files. 

2.  A  user  with  more  than  one  job  order  number  can 
share  files  between  the  job  order  numbers  since 
they  are  the  owner  of  all  files  in  the  root 
directory;  thus  serving  as  a  group. 

2.  DISADVANTAGES 

1.  Longer  path  name  to  files 

2.  CAS  files  need  to  be  maintained  and  carefully 
kept  in  synchronous  with  the  VMS  User 
Authorization  File. 
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A  ANALYZE 


NOTE 

In  this  section  the  following  convention  will  be 
assumed: 

Convention  Meaning 

<DATE>  date  of  the  form  DD_MMM_YYYY 

(previous  day) 

This  section  provides  an  overview  of  the  way  the  analysis 
for  CAS  is  completed.  On  each  node  in  the  VAXcluster, 
shortly  after  midnight,  DAILY_J0BS.COM  is  executed.  In 
addition  to  its  other  tasks,  DAILY_JOBS.COM  controls  the 
accounting  period  by  closing  the  accounting  file  and 
renaming  the  lowest  version.  (An  accounting  period  is 
typically  24  hours,  beginning  and  ending  at  00:05.  However, 
the  period  from  Saturday  at  00:05  through  Tuesday  at  00:05 
is  defined  as  one  accounting  period.)  DAILY_J0BS.C0M  also 
executes  GENACTDATA.COM  which  analyzes  the  VMS  Accounting 
File.  GENACTDATA.COM  completes  two  tasks;  first  it  breaks 
down  the  Accounting  File  into  two  files  of  the  form 
<DATE>_acctng_prime.dat  and  <DATE>_acctng_discnt.dat.  Next, 
it  breaks  down  these  two  files  into  separate  classes,  BATCH, 
DIALUP,  and  DIRECT  CONNECT.  These  files  are  named  as 
follows:  DTx_SUMMy_<DATE>.DAT;  where  x  is  the  node  number, 

and  y  indicates  the  contents  of  the  accounting  summary  files 
(see  Fig.  3.1). 


y  Contents  of  summary  file 

1  DIALUP  -  normal  CPU 

2  DIALUP  -  discount  CPU 

3  Dedicated  Port  -  normal  CPU 

4  Dedicated  Port  -  discount  CPU 

5  BATCH  -  normal  CPU 

6  BATCH  -  discount  CPU 


Fig.  3.1 
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At  twenty  minutes  past  midnight,  a  time  chosen  to  guarantee 
that  the  requisite  accounting  summary  files  have  been 
created,  the  main  routine  in  the  analysis  process, 
ANALYZE.COM  is  executed. 

ANALYZE.COM  is  the  routine  which  ties  all  of  the  accounting 
together  across  the  VAXcluster.  The  operations  of 
ANALYZE.COM  follow: 

1.  Generates  templates  for  an  error  file, 
<DATE>_ERRORS.DAT,  and  the  Accounting  Transfer  File 
(ATF)  <DATE>_CDCTEMP.DAT.  These  are  both  indexed  files 
with  the  primary  key  being  job  order  number,  and  the 
secondary  key  being  username.  The  ATF  is  created  by 
CDCTEMP.FDL,  and  the  error  file  is  created  by  ERROR. FDL. 
Both  of  these  '.FDL'  files  contain  a  VMS  File  Definition 
Language  (FDL)  in  order  to  call  the  VMS  $  CREATE/FDL 
command  to  execute. 

2.  Calls  FILESPACE.COM  to  determine  the  filespace  used  by 

each  user  for  each  authorized  job  order  number.  This  is 
completed  by  sequentially  reading  from  the  CAF, 
appending  the  job  order  number  to  the  user  intials,  (as 
the  first  level  subdirectory),  and  forming  the  VMS  $DIR~ 
/SIZE-USED...  command  to  determine  the 

filespace  used  through  that  user's  directory  tree. 
Output  goes  to  a  temporary  file  <DATE>_B LOCKS. DAT.  (If 
a  device  is  sensed  to  be  OFFLINE,  this  record  is 
skipped,  and  the  job  continues.  Later  in  the  process,  a 
record  gets  written  to  the  error  file  to  flag  the 
problem) . 

3.  Calls  STOREBLOCKS.EXE  to  start  populating  the  ATF,  which 
holds  the  analyzed  accounting  output  to  be  transferred 
to  the  Mass  Store  System  (MSS)  for  Code  189.3  to  access, 
(see  Fig.  3.2) 

a.  sequentially  reads  each  record  from 

<DATE>_BLOCKS . DAT 

b.  applies  storage  charges  to  each  record  based  on  the 
current  charging  rates.  (Stored  in  CHARGES. INC) 


4.  The  ATF  is  now  ready  to  be  populated  with  the  rest  of 
the  resource  accounting  information. 

5.  Logical  names  are  assigned  to  each  of  the  six  created 
accounting  summary  files  for  each  processor,  in  the  form 
of  FOROxy;  where  x  is  the  node  number,  and  y  is  the 
accounting  summary  file  number  (see  Fig.  3.1). 
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6.  A  foreign  command  symbol  is  defined  for  executing 
ANALYZE.EXE  with  the  input  parameter  xy;  where  x  and  y 
are  as  discussed  above.  ANaLYZE.EXE  can  determine,  by 
this  parameter,  not  only  which  rates  to  apply  to  the 
data,  but  also  where  to  get  the  data.  By  converting  the 
character  string  xy  passed  to  ANALYZE.EXE,  the 
appropriate  logical  name  can  be  accessed  to  read  the 
data. 

7.  ANALYZE.EXE  is  called  once  for  each  of  the  files 

associated  with  a  logical  name  and  is  executed,  at  most, 
six  times  per  processor.  ANALYZE.EXE: 

a.  determines  which  file  to  get  the  accounting  summary 
data  from 

b.  sequentially  reads  each  line  of  data  from  the 

summary  file 

c.  checks  the  Account  number  field  to  guarantee  that  it 
is  decodab le 

d.  if  not  decodable,  the  record  is  skipped 

e.  Account  number  is  unpacked  into  the  unique  10 

character  job  order  number 

f.  CPU  and  Connect  Time  resources  are  broken  down  into 
seconds  by  GETSECNDS.EXE 

g.  charges  are  applied  to  all  accountable  resources. 
(CPU,  Connect  Time,  Pages  printed.  Volumes  mounted) 

h.  performs  keyed  read  on  the  ATF,  by  using  job  order 
number  and  username  to  locate  the  appropriate  record 

i.  if  the  record  is  not  located,  a  record  gets  written 
to  the  error  file 

j.  located  record  gets  updated  by  adding  resource  and 
resource  charge  information  from  the  accounting 
summary  file  to  the  current  values  of  these  fields 
in  the  ATF. 


8.  Note  that  if  an  accounting  summary  file  is  determined  to 
be  empty,  ANALYZE.EXE  is  not  called  for  that  file. 

9.  CDCDUMP.EXE  is  called  to  convert  the  indexed  file,  ATF, 
to  a  sequential  file. 
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10.  CDCLIST.EXE  is  called  to  generate  a  printable  listing  of 
the  transfer  file  on  VMS.  (This  is  for  comparison 
purposes,  to  guarantee  that  the  ATF  is  transferred 
accurately) . 

11.  Provides  a  method  of  automatically  sending  the  ATF 
across  to  the  MSS  using  MUX200,  (a  200UT  protocol 
emulator  between  VMS  and  NOS/BE  on  CDC  machines),  to  one 
of  the  NOS/BE  CDC  CYBER  machines,  and  then  onto  the  MSS. 
GENMUXJOB.COM: 

a.  creates  the  batch  job  MUXLOAD.COM,  and  submits  it  to 
run  at  five  minutes  past  seven  on  Monday  through 
Friday.  (For  holidays  and  other  times  when  the 
CYBER  machines  may  be  down,  a  file 
HOLIDAY_SUBMIT. TIME  is  scanned  for  an  alternate  time 
to  SSUBMIT  MUXLOAD.COM) 

b.  MUXLOAD.COM  contains  all  of  the  necessary  VMS,  $MUX, 
and  NOS/BE  commands  to  effect  the  transfer  from  the 
VAXcluster,  through  the  CYBER  machines,  and  then 
onto  the  MSS. 


12.  Sends  listings  of  the  CAF,  PAF,  RIGHTSLIST.DAT,  and  the 
UAF  to  the  printer. 

13.  Purges  any  summary  files  which  are  older  than  twenty 
days . 

14.  EXITS. 


Though  it  may  appear  to  be  a  bit  cumbersome  to  include  so 
many  calls  to  ANALYZE.EXE,  it  was  determined  to  be  the  most 
appropriate  option  since  nodes  may  be  added  to  the  Cluster, 
or  taken  away,  without  major  modification  to  the  analysis 
scheme.  In  addition,  if  other  resource  charging  schemes  are 
eventually  implemented,  such  as  the  addition  of  dedicated 
lines  which  generate  a  surcharge  in  Connect  Time  rates,  only 
minor  changes  would  have  to  be  made. 

Note  that  the  whole  analysis  process  is  completed 
automatically  without  any  human  intervention.  ANALYZE.COM 
resubmits  itself  daily  in  order  to  complete  its  task,  and  is 
programmed  to  resubmit  itself  and  exit  on  Sunday  and  Monday 
mornings  before  doing  any  work,  since  the  accounting  period 
is  not  closed. 
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Format  of  the  Accounting  Transfer  File  (ATF) 


Position  1-10 
Position  11-14 
Position  15-21 
Position  22-2.9 
Position  30-39 
Position  40-47 
Position  48-52 
Position  53-59 
Position  60-61 
Position  62-67 
Position  68-75 
Position  76 
Position  77 


Job  Order  Number  (primary  key) 
User  Initials  (secondary  key) 
Connect  Time  (hours) 

Connect  Time  Charge 
CPU  Time  (seconds) 

CPU  Time  Charge 

Number  of  Pages  Printed 

Print  Charge 

Number  of  Tape  Mounts 

Number  of  blocks  of  Disk  space 

File  charge  based  upon  30  days 

Job  Order  Number  Flag 

User  Flag 


FIG  3.2 
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5  FUTURE  ENHANCEMENTS 

The  following  section  includes  some  enhancements  planned  for 
the  future. 

I .  UPDATE 
B.  LIST 

-  provide  more  varieties  of  listings 

F.  MODIFY 

a. )  CHANGE 

-  this  module  needs  to  be  enhanced 

-  currently,  some  UAF  modification  needs  to 
be  completed  manually 

b. )  DELETE 

-  this  module  needs  to  be  enhanced 

-  currently,  some  UAF  modification  needs  to 
be  completed  manually 

G.  HELP 

-  some  online  HELP  needs  to  be  developed. 


III.  ANALYZE 

A  more  reliable  means  of  transferring  the  ATF  for 
189.3  will  be  implemented  once  the  HYPERchannel 
link  is  installed  between  the  VAX  Systems  and  the 
CDC  machines. 
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